A computerized axial tomography scan (commonly known as a CAT scan or a CT scan) is an x-ray procedure which combines many x-ray images with the aid of a computer to generate cross-sectional views of the internal organs and structures of the body. In each of these views, the body image is seen as an x-ray “slice” of the body. Typically a plurality of parallel slices are taken at different levels of the body, that is, at different axial (z-axis) positions. This recorded image is called a tomogram, and “computerized axial tomography” refers to the recorded tomogram “sections” at different axial levels of the body. In multislice CT, a two-dimensional array of detector elements replaces the linear array of detectors used in conventional CT scanners. The 2D detector array permits the CT scanner to simultaneously obtain tomographic data at different slice locations and greatly increases the speed of CT image acquisition. Multislice CT facilitates a wide range of clinical applications, including 3D imaging, with a capability for scanning large longitudinal volumes with high z-axis resolution.
Magnetic resonance imaging (MRI) is another method of obtaining images of the interior of objects, especially the human body. More specifically, MRI is a non-invasive, non-x-ray diagnostic technique employing radio-frequency waves and intense magnetic fields to excite atoms in the object under evaluation. Like a CAT scan, MRI provides computer-generated image “slices” of the body's internal tissues and organs. As with CAT scans, multislice MRI facilitates a wide range of clinical applications, including 3D imaging, and provides large amounts of data by scanning large volumes with high z-axis resolution.
However, in medical imaging, the popularity of image capture modalities such as multislice CT and MRI is resulting in an exponential increase in the amount of volumetric data that needs to be stored and transmitted. The increased data is taxing the interpretation capabilities of radiologists. One of the recommended workflow strategies for radiologists to overcome the data overload is the use of volumetric navigation (see, e.g., J. S. Batchelor, 3D navigation holds promise for image overload, www.auntminnie.com, July 2005). This allows the radiologist to seek a series of oblique slices through the data instead of the more typical axial slices, where each oblique slice intersects a plurality of axial slices. In a typical setup, the volumetric data is stored on a picture archive and communication system (PACS) server, possibly in a compressed form, and a client, such as a diagnostic workstation, requests axial slices from the server. Typical client-server architectures that enable volumetric navigation are as follows:                Server-centric: In this architecture, when a client requests an oblique slice, the server performs required decompression and interpolation to compute the requested oblique slice. Next, the oblique slice image is transmitted to the client (possibly after compression). In this case, the server carries the entire computational load. The client needs very few resources (thin-client). The AquariusNET server by TeraRecon, Inc. is an example of a server using this paradigm.        Client-centric: In this architecture, the client is a full-fledged 3D workstation. Data corresponding to all the axial slices is transmitted from the server to the client. The client uses its 3D capabilities to render the desired oblique slice.        
Both of these architectures have certain drawbacks. The main drawback of the server-centric architecture is that, in case of multiple requests, the data transmitted in response to previous requests cannot be reused. Also, the server might be able to service only a limited number of clients as a result of the computational load. One of the chief drawbacks of the client-centric architecture is that, in most cases, the rendering cannot be started until all the slice data is received. With the increasing axial resolution for CT and MRI scans, a single study can easily contain 50-100 megabytes (MB) of data or more. This can result in an unacceptable workflow. Also, this architecture places high demands on the client in terms of memory and computational power.
The increased resolution of CT and MRI data has also sparked interest in compression algorithms for storage and transmission purposes. One such compression algorithm is JPEG2000. JPEG2000 is an emerging international standard, ratified by the International Standards Organization (ISO), for image and video compression. The JPEG2000 standard has several parts. Part 1 of JPEG2000 (refer to Information Technology—JPEG2000 Image Coding System, ISO/IEC International Standard 15444-1, ITU Recommendation T.800, 2000) defines a core coding system that is aimed at minimal complexity while satisfying 80% of the applications. Part 2 of JPEG2000 (refer to Information Technology—JPEG2000 Image Coding System: Part II Extensions, ISO/IEC International Standard 15444-2, ITU Recommendation T.801, 2001) is aimed at enhancing the performance of Part 1 with more advanced technology, possibly at the expense of higher complexity. In November 2001, the DICOM Working Group 4 (compression group) approved JPEG2000 as an accepted compression option (refer to Digital Imaging and Communications in Medicine (DICOM) Supplement 61: JPEG2000 Transfer Syntaxes, 2003). Apart from superior compression performance, desirable features of JPEG2000 for compression of medical images include:                Lossless as well as lossy compression capability.        Capability to work seamlessly for different bit-depth imagery.        Scalability (resolution, quality, and spatial).        
JPEG2000 Interactive Protocol (JPIP) is Part 9 of the JPEG2000 standard (refer to Information Technology—JPEG 2000 image coding system—Part 9: Interactivity tools, APIs and protocols—(JPIP) Common Text, ISO/IEC 15444-9:2004, ITU-T Recommendation T.808, wg1n3314, July 2004). It defines a protocol for communication between a client and a server serving JPEG2000-compressed images. The JPIP protocol allows the client to request JPEG2000-compressed data associated with a particular region and resolution.
A good example of a client-server system based on JPEG2000 and JPIP can be seen in the ‘kdu_show’ application of the ‘Kakadu’ software package developed by David Taubman (D. Taubman, Kakadu Software, available at www.kakadusoftware.com). Krishanan et al. proposed a scheme for JPIP supported interactive browsing of large volume medical imagery (K. Krishnan, M. W. Marcellin, A. Bilgin, and M. Nadar, “Compression/Decompression Strategies for Large Volume Medical Imagery,” Medical Imaging 2004: PACS and Imaging Informatics, Proc. SPIE Vol. 5371, pp. 152-159, San Diego, Calif., February 2004). Version 5.0 of the Kakadu software has introduced support for this feature. However, the limitation of this method is that the region of interest is restricted to be a cuboid. Hence, the framework is not very suitable for obtaining arbitrary oblique slices from the server.
While such systems may have achieved certain degrees of success in their particular applications, there is a need for new client-server architectures that are more responsive to the needs of the end user, particularly a user who is attempting to use and control the data to obtain a desired oblique slice of a 3D volume.